In this new section of the course will cover parts of the electron API that gets shared across both
the main and the renderer processes, I say parts and not modules, as these shared objects often include
existing objects from notorious with electron specific extensions.
For example, the first object will look at the process object.
As you might know, Notat provides this process object and this is mentioned and linked to in the electron
process.
Documentation here process then represents a running, no touchiest process.
In our case, the main process, electron simply adding its own properties and method to the existing
object, meaning there's no module to import process, simply exists in the global scope of both the
main and the render a process node.
However, process is only available in the renderer process with node integration enabled.
So with that, let's start by logging out this global object from both processes.
I'll just get rid of Renderer database, logging it in line.
There and same for the main process, by adding a log in the global scope of Mendes's save both files
and when our app relaunches, we see process logged in the renderer or the browser windows dev tools
with a lot of properties and methods, some being notorious as own and others being electron's added
functionality over in my terminal, the exact same object being shared across processes.
I won't be covering notes, native properties and methods, but let's see a few of these electron additions.
For example, a bit further down, we see a number of properties on the processes version property that's
providing all sorts of version numbers for software used by our app in indexed HTML.
Change this log to now instead log out process DOT versions.
I won't do the same in the main process as it's exactly the same.
Save this time reloading main window manually and there an object containing every version from electron
itself, node open SSL and even the version of Google's V8 engine.
This is all running on.
Another very useful property is processed DOCTYPE.
This tells us the type of process we're accessing the property from.
I'll add this to the main process as well as this time they'll be different.
Save both files.
And there in the browser window or renderer process, we get renderer, whereas in the main process
there's logged browser, which is what the main process is referred to by node.
Knowing which process we are in is particularly useful when creating shared code such as the shared
modules will cover in the section.
Other properties include checking whether the app was installed from the Windows App Store or alternatively,
the Mac App Store, again, useful for displaying specific content or offers to users.
Then a bit further down, we get to process methods, things like checking when the app was launched,
CPU usage by the mean process and several other informational getters.
The two methods I want to demonstrate, however, being crash and having these two methods to exactly
what they suggest crash or hang the process.
They're called in.
Let's see an example.
I'll remove this log from the main process over to indexed HTML.
Add a button to hang this browser window worth with an unclick property calling process.
Dot Hangu.
And render a break before this button to have it on its own line and as before, to better demonstrate
the renderer hanging out at a simple log interval set interval with a callback in which our logout eye
and then incremented starting with eye equals one, making this interval execute every half a second
or 500 milliseconds, save both files to reload the app.
We see that log interval.
But when I click hang, everything stops as this window is now in a simulated hanging state.
Equally, we can crash the window.
I'll remove this log, duplicate the hang button this time calling process dot crash.
Crash renderer save.
We now can't reload this window with command or as it's currently hanging, so in the terminal, execute
a node on restart with R.S..
Click this crash button and it breaks everything or crashes.
The reason we might want to simulate this being that we can now implement and test handlers for these
conditions.
For example, in the main process, we can reload a crashed renderer.
This, of course, being a very crude solution.
But let's see what this might look like.
We can listen for a renderer having crashed on its web content, which makes sense as that's what's
crashed.
The window remained, but the content and the dev tools crashed.
In other words, the web content.
So create window listen on main windows web content with on for the crashed event past.
There's a callback in which we can reload the crashed window after a second or two at a time out.
Executing main window, reload after, say, one second, if we don't add the small delay, the reload
will often not work.
We need to really allow the crash to happen, fully save this.
Crash the window process again.
And one second later, that main Windows crashed, web content is reloaded again, this is by no means
a solution you should use in a production up, but it shows how to implement solutions for these events.
I'd encourage you to explore this object further as it can provide some very valuable information.
And if you're not familiar with the process, object in the context of notices that would also be worth
a look over.
I've added the link in the lessened resources.